Wellness analysis system

ABSTRACT

A wellness analyzer is in communications with sensors that generate real-time physiological data from a patient. The wellness analyzer is also in communications with databases that provide non-real-time information relevant to a medical-related assessment of the patient. In a diagnostic mode, a monitor layer inputs the sensor data and adjunct layers input the database information. Adjunct layer logic blocks process the database information so as to output supplemental information to the monitor. Monitor logic blocks process the sensor data and the supplemental information so as to generate a wellness output. In a simulation mode, a simulator generates at least one parameter and the monitor generates a predictive wellness output accordingly.

REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 13/009,505, filed Jan. 19, 2011, titled “WELLNESS ANALYSIS SYSTEM,” which claims priority benefit under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application Ser. No. 61/296,467, filed Jan. 19, 2010, titled “WELLNESS ANALYSIS SYSTEM,” which is incorporated in its entirety by reference herein.

BACKGROUND OF THE INVENTION

Various monitoring technologies are available for assessing one or more physiological systems. For example, pulse oximetry is a widely accepted noninvasive procedure for measuring blood oxygen saturation and pulse rate, which are significant indicators of circulatory system status. Pulse oximeters capable of reading through motion induced noise are disclosed in at least U.S. Pat. Nos. 6,770,028, 6,658,276, 6,650,917, 6,157,850, 6,002,952, 5,769,785 and 5,758,644; low noise pulse oximetry sensors are disclosed in at least U.S. Pat. Nos. 6,088,607 and 5,782,757; all of which are assigned to Masimo Corporation, Irvine, Calif. (“Masimo”) and are incorporated by reference herein.

Physiological monitors and corresponding multiple wavelength optical sensors are described in at least U.S. patent application Ser. No. 11/367,013, filed Mar. 1, 2006 and titled Multiple Wavelength Sensor Emitters and U.S. patent application Ser. No. 11/366,208, filed Mar. 1, 2006 and titled Noninvasive Multi Parameter Patient Monitor, both assigned to Masimo Laboratories, Irvine, Calif. (Masimo Labs) and both incorporated by reference herein.

Further, physiological monitoring systems that include low noise optical sensors and pulse oximetry monitors, such as any of LNOP® adhesive or reusable sensors, SofTouch™ sensors, Hi-Fi Trauma™ or Blue™ sensors; and any of Radical®, SatShare™, Rad-9™, Rad-5™, Rad-5v™ or PPO+™ Masimo SET® pulse oximeters, are all available from Masimo. Physiological monitoring systems including multiple wavelength sensors and corresponding noninvasive blood parameter monitors, such as Rainbow™ adhesive and reusable sensors and RAD-57™ and Radical-7™ monitors for measuring SpO₂, pulse rate (PR), perfusion index (PI), pleth variability index (PVI), signal quality, HbCO, HbMet and Hbt among other parameters are also available from Masimo.

Various other monitoring technologies can assess the status of other physiological systems. U.S. Pat. App. Publication No. 2008/0108884 A1 filed Sep. 24, 2007 and titled Modular Patient Monitor describes monitoring of blood constituent parameters and respiration rate as well as blood pressure, blood glucose, ECG, CO₂ and EEG to name a few and is also assigned to Masimo and incorporated by reference herein.

SUMMARY OF THE INVENTION

Physiological monitoring is advanced with any methodology that integrates the many otherwise disparate monitoring technologies and measured parameters. Further, physiological monitoring may be enhanced by taking into account other patient data including medical history, medications, lab work, diagnostic test results among other data outside of real-time patient monitoring. Also, volumes of medical research and vast databases of scientific knowledge can be accessed to further supplement and integrate the results of real-time monitoring.

A wellness analysis system advantageously integrates real-time sensor data regarding the status of any or all of a body's circulatory, respiratory, neurological, gastrointestinal, urinary, immune, musculoskeletal, endocrine and reproductive systems so as to generate a wellness output. In addition, a wellness analysis system stores traces of measured parameters during real-time patient monitoring so as to characterize a patient's response over time, creating a “virtual patient” that can be tested with simulated data, resulting in a predictive wellness output.

An aspect of a wellness analyzer is sensors that generate real-time physiological data from patient sites. Further, databases provide non-real-time information relevant to a medical-related assessment of the patient. A wellness monitor, in a diagnostic mode, inputs the sensor data. Adjunct layers input the database information. Adjunct layer logic blocks process the database information so as to output supplemental information to the wellness monitor. Wellness monitor logic blocks process the sensor data and supplemental information so as to generate a wellness output.

Another aspect of a wellness analyzer is physiological sensor data input to a monitor layer. Physiological parameters are derived based upon the sensor data. Physiological system statuses are generated based at least in part upon the parameters. A wellness output is based upon these physiological system statuses.

A further aspect of a wellness analyzer is a monitor layer means for generating a wellness index responsive to real-time sensor data. An adjunct layer means is coupled to the monitor layer means for supplementing the monitor layer wellness index according to non-real-time data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a general block diagram of a wellness analysis system;

FIG. 2 is a general flow diagram of a wellness analyzer embodiment;

FIG. 3 is a detailed flow diagram of a wellness analyzer embodiment;

FIG. 4 is a detailed flow diagram of a wellness monitor embodiment;

FIG. 5 is a block diagram of a parameter logic block;

FIG. 6 is a block diagram of a system logic block;

FIG. 7 is a block diagram of a diagnostic logic block; and

FIG. 8 is a general flow diagram of a predictive wellness monitor embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a wellness analysis system 100 having a wellness analyzer 110 in communications with various forms of patient data. In particular, sensors 112 provide real-time patient data responsive to one or more of a patient's circulatory, respiratory, neurological, gastrointestinal, urinary, immune, musculoskeletal, endocrine and reproductive systems. Further, various local, regional, nationwide or worldwide databases provide non-real-time patient-related data. Local databases include hospital records 120 that communicate with the wellness analyzer 110 via a local area network (LAN) 130. Hospital records 120 may include patient history 122, recent lab work and tests 124 and prescribed medications and therapies 128, to name a few. Non-local databases 140 include patient-specific data 142 and non-specific data 144 that are communicated to the wellness analyzer 110 via a wide area network (WAN) 150. Patient-specific data 142 may include family history, genealogy, genetic and environmental information, as a few examples. Non-specific data 144 may include scientific research and other information that generally relates to known patient physiology and history, such as genetic, pharmacological, medical and environmental research, to name a few.

Advantageously, the wellness analyzer 110, in a diagnostic mode, utilizes the sensor data 112 in conjunction with historical data 120 and research 140 so as to derive a comprehensive wellness output 116 for a patient. In an embodiment, the wellness output 116 is a simple index useful for an initial screening of individuals. For example, the index may be a range of values, such as 1 through 10, with 10 indicating no significant health issues and 1 indicating the existence of one or more potentially life-threatening conditions. In another embodiment, the wellness output 116 is a comprehensive and detailed listing of specific health issues sorted according to priority or urgency for follow-up examination, observation and treatment.

Further, the wellness analyzer 110 characterizes a patient as it determines the wellness output 116. In this manner, the wellness analyzer 110 creates an internal patient model or “virtual patient.” The virtual patient can then be tested, in a simulation mode, with statistical inputs in lieu of, or in addition to, sensor data 112 so as to determine a predictive wellness output 118. Advantageously, predictive wellness 118 indicates how a patient is likely to respond to various physical, medical and environmental conditions so as to reveal physiological strengths and weaknesses. For example, predictive wellness 118 may reveal a risk of an immediate deterioration in health due to, for example, septic shock, infection, embolism, pneumonia and pharmaceutical side-effects, to name a few. Predictive wellness 118 may also reveal longer-term susceptibility to particular diseases or disease states, such as thrombosis, certain cancers, diabetes and heart disease, as a few examples.

FIG. 2 illustrates a wellness analyzer embodiment 200 having a wellness monitor 210 and one or more adjunct layers 220-260 coupled to the wellness monitor. The wellness monitor 210 processes real-time data 280, such as from sensors 112 (FIG. 1). The adjunct layers 220-260 each process non-real-time data 290, such as from hospital records 120 (FIG. 1) and other databases 140 (FIG. 1). In an embodiment, the adjunct layers 220-260 are specialized according to the data source, such as a lab work layer 220, a pharmaceutical or medications layer 230, a patient history layer 240, a genetics layer 250 and an environmental layer 260, to name a few. The wellness analyzer layers 210-260 extract features from the real-time data 280 and non-real-time data 290 so that the wellness monitor 210 may derive a wellness output 216, as described above.

As shown in FIG. 2, the wellness analyzer layers 210-260 also store an internal analyzer state 272, including extracted features and traces of the feature extraction process. The analyzer state 272 may include the “virtual patient” characterization described above. A simulator 270 layer utilizes the analyzer state 272 and, perhaps, the input data 280, 290 to generate statistical data 274 to the wellness monitor 210, so as to generate a predictive wellness output 218, also described above. The predictive wellness output 216 may also include the internal analyzer state 272 so as to determine what led to the prediction.

FIG. 3 illustrates a wellness analyzer 300 embodiment having a monitor layer 310, a labwork layer 330 and a pharmaceutical layer 350 among other layers not shown. The monitor layer 310 has sensor 301 inputs, logic blocks 320 and a wellness indicator 309 output. In this particular embodiment, the logic blocks 320 are organized into three levels including parameter 322, system 324 and diagnostic 328 levels. The parameter “P” logic blocks 322 process sensor data so as to derive parameters 312, which are numerical variables and, perhaps, waveforms indicative of the status of various physiological subsystems. For example, an optical sensor attached to a fleshy tissue site can generate numerical parameters such as oxygen saturation, pulse rate and total hemoglobin among others, as well as a plethysmograph waveform, which are related to arterial and/or venous blood flow at a particular body location. This information, in turn, provides some information regarding the body's circulatory system. Although selected parameters can be displayed by the monitor, at this level most of the derived information is internal to the machine.

The system “S” logic blocks 324 are responsive to parameter levels, slopes, trends, variability, patterns and waveform morphology, instantaneously and over time, so as to provide system indicators 314, which describe some aspect of the physiological status of one or more of the biological systems enumerated above, including the circulatory, respiratory and neurological systems, to name a few. For example, physiological system indicators may vary from a specified number of measured events per unit time to a general measure of physiological system health. These physiological system indicators are vaguely analogous to blood chemistry results from a lab, i.e. an indicator may be a measured number, such as “significant desaturations per minute” along with a specified acceptable or normal range. As such, a system indicator is typically available for a nurse or doctor's review, but does not provide an overall diagnosis of a patient condition. The system indicators 314 are, in turn, input to one or more diagnostic logic blocks 328.

The diagnostic “D” logic blocks 328 generate a wellness output 309, i.e. one or more decisions regarding a person's health that are intended as an ultimate diagnosis for a caregiver's evaluation. A wellness output 309 can range from a relatively mild diagnosis, such as “occasional atrial arrhythmias” to significant health concerns, such as “apnea” to immediate and life threatening concerns, such as “congestive heart failure.” Further examples are described below with respect to FIG. 4. In other embodiments, different types, numbers and organizations of logic blocks may be utilized in the monitor layer 310.

Also shown in FIG. 3, other wellness analyzer layers 330, 350 also have logic blocks that feed into the monitor layer 310 and/or other layers. For example, the labwork layer 330 may have system level logic blocks that determine where a measured value, such as a particular blood factor, falls relative to a normal range of values. That result would then input into a monitor layer 310 diagnostic block 328, which combined with sensor derived measurements would yield a particular diagnosis. As another example, the pharmaceutical layer 350 may have diagnostic level logic blocks that compare known side-effects of currently prescribed drugs with one or more system-level logic block outputs 314 on the monitor layer 310 so as to generate an input to a diagnostic-level logic block 328 on the monitor layer 310. In this manner, the monitor 310 takes into account known drug side-effects in determining the wellness output 309. In various embodiments, there may be a back and forth flow of information 360 between adjunct layers 330, 350 and between the monitor layer 310 and the adjunct layers 330, 350 involving one or more levels of logic blocks in each layer.

FIG. 4 shows an illustrative wellness monitor embodiment 400 having sensor 401 inputs, logic blocks 403 and a wellness indicator 409 output. The logic blocks 403 include parameter 404, system 406 and diagnostic 408 blocks. For example, at the parameter level 404, an optical sensor 412 generates an absorption plethysmograph from which a first parameter block 420 generates blood oxygen saturation 422 and pulse rate 424. An acoustic sensor 414 generates breathing sound waveforms from which a second parameter block 430 generates a respiration rate 432. A temperature sensor generates a body temperature measurement 416. A blood pressure cuff 418 generates a pressure plethysmograph from which a third parameter block 440 generates systolic and diastolic blood pressure measurements 442.

At the (physiological) system level 406, a first system block 450 inputs oxygen saturation 422 and pulse rate 424 and generates a circulatory system output 452. For example, the first system block 450 may indicate at a particular point in time that oxygen saturation 422 is falling in conjunction with a relatively steady pulse rate. A diagnostic logic block 480 responds to the circulatory system output 452 to generate a wellness state output 409 comprising a “cardiac distress” message. Details of the message alert the caregiver that something is wrong with the patient's heart as it is unable to compensate a drop in oxygen saturation with an increase in circulatory system blood flow.

Also at the system level 406, a second system block 460 inputs oxygen saturation 422 and respiration rate 432 and generates a respiratory system output 462. For example, the second system block 460 may indicate at a particular point in time that oxygen saturation 422 is falling in conjunction with a rising respiration rate. A diagnostic logic block 480 responds to the respiratory system output 462 to generate a wellness state output 409 comprising a “respiratory pathway blockage” message. Details of the message alert the caregiver that a rising respiration rate is not resulting in increased oxygen delivery to the lungs.

Further at the system level 406, a third system block 470 inputs body temperature 416 and blood pressure 442 and generates a circulatory system output 472 related to hemodynamic stability. The third system block 470 may also input pulse rate 424 and respiration rate 432 to generate a multiple system output 472 responsive to these four significant vital signs.

As described with respect to FIGS. 1-4, above, the wellness analyzer 110 (FIG. 1) can range from a general purpose computer to a special-purpose signal processor or from a processor array to a distributed network of computers or other processing devices. Also as described above, the wellness monitor 210 (FIG. 2) and adjunct layers 220-260 (FIG. 2) can be implemented in hardware, software, firmware or a combination of these. In an embodiment, the wellness analyzer 110 (FIG. 1) is a single instrument having plug-ins, one or more displays, keyboards, various standard communications interfaces, one or more signal processors and an instrument management processor. In an embodiment, the various processing layers 210-260 (FIG. 2) are implemented in software and/or firmware. In an embodiment, the various logic blocks 320 (FIG. 3) are subprograms or subroutines or otherwise identifiable portions within software and/or firmware.

FIG. 5 illustrates details of a parameter logic block 500. As described with respect to FIG. 3 (322) above, a parameter logic block has a sensor input 501 and parameter 509 output. The sensor input 501 can be any of a variety of sensor signals such as photodiode detector current generated by an optical sensor, piezoelectric current from an acoustic sensor or electrode voltage from an ECG sensor, to name just a few. A hardware interface 510 apart from the parameter block 500 drives the sensor, if necessary, and conditions, samples and digitizes the sensor input 501 into sensor data 512. A signal extraction process 520 extracts one or more physiological signals 525 from the sensor data 512. For example, signal extraction for a pulse oximetry sensor includes demodulating the red and IR signal components. The sensor signal(s) 525 are then analyzed 530 so as to derive physiological parameters 509. For pulse oximetry, signal analysis 530 would include deriving a red over IR ratio and using that ratio with a lookup table to calculate an oxygen saturation parameter.

FIG. 6 illustrates details of a system logic block 600. As described with respect to FIG. 3 (324) above, a system logic block 600 has parameter inputs 601 as well as, perhaps, sensor data inputs. The system logic block 600 also has a system status 609 output. In an embodiment, a system logic block 600 has an input selector 610, a feature extractor 620, feature storage 630 and a feature analyzer 640. A controller 390 (FIG. 3) provides control inputs (not shown) to each of the input selector 610, feature extractor 620, feature storage 630 and feature analyzer 640, as described in further detail below. In an embodiment, the feature extractor 620 has level 622, trend 624, pattern 625, statistics 627 and morphology 629 functions, as a few examples.

As shown in FIG. 6, the input selector 610 determines which parameter blocks 322 (FIG. 3) feed its particular system block 324 (FIG. 3). Further, the input selector 610 routes the selected parameters to specific feature extractor functions. The level function 622 is responsive to input parameters 603 rising above or falling below a predetermined threshold. The trend function 624 is responsive to input parameters 603 having a positive or negative rate of change above a predetermined absolute value over a predetermined time interval. The pattern function 625 is responsive to a predetermined parameter behavior over a predetermined time interval, such as threshold crossings per minute. The statistics function 627 determines parameter behavior over a predetermined sample size, such as mean, variance and correlation (with other parameters) to name a few. The morphology function 629 analyzes sensor waveform characteristics, such as plethysmograph dicrotic notch behavior, as one example. Other feature extraction functions not shown may include an FFT function, to determine frequency characteristics such as detection of sensor waveform modulation, among others. Using FIG. 4, described above, as a system logic block example, the input selector of the first system block 450 (FIG. 4) routes both the SpO₂ parameter and the PR parameter to the trend 624 function, so that the system block output 452 (FIG. 4) is responsive to upward or downward trends of both SpO₂ and pulse rate.

Further shown in FIG. 6, the feature analyzer 640 inputs the extracted features 607 so as to indicate the functioning of a physiological system, such as the circulatory, respiratory, neurological and other systems cited above. In an embodiment, the status output 609 is a list of status codes indicating a particular physiological system is okay or is in various degrees of distress. In an embodiment, the feature analyzer 640 accesses a look-up table 650 to generate the status codes according to extracted features. In an embodiment, the status codes are prioritized according to severity. In an embodiment, the look-up table 650 is uploaded from the controller 390 (FIG. 3) according to particular system logic block inputs and functions.

Also shown in FIG. 6, feature storage 630 stores traces of selected input parameters along with extracted parameter features. In this manner, each of the system blocks 600 builds a characterization of the patient with respect to the particular physiological system monitored. The sum of this patient characterization across all system blocks creates a “virtual patient” that can be tested by a simulator 870 (FIG. 8).

During simulation, independent parameters 601 and, potentially, some sensor data are simulated and dependent parameters are “played-back” from feature storage 630 accordingly. The input selector 610 combines the simulated parameters 601 and the playback parameters 632 as inputs to the feature extractor 620. The feature analyzer 640 then responds to the simulated extracted features 607 so as to determine a corresponding system status 609 according to how the patient historically responds. Simulation is described in further detail with respect to FIG. 8, below.

FIG. 7 illustrates details of a diagnostic logic block 700 having system status 701 inputs and a wellness output 703. The diagnostic block 700 comprises an expert system 710, a diagnostic knowledgebase 720 and an output generator 730. The expert system 710 receives the system status 701 inputs, which are generated by the various system logic blocks 600 (FIG. 6). In an embodiment, system status 701 is input as status codes, as described above. The expert system 710 compiles the status codes and interprets those codes according to the diagnostic knowledge base 720 so as to generate a diagnostic output 712. In an embodiment, the diagnostic output 712 is one or more diagnostic codes, which are a compiled diagnostic interpretation of the system status codes. The output generator 730 determines the form and format of the wellness output 703 according to the diagnostic codes 712. In an embodiment, the wellness output 703 is any or all of a wellness index 732, diagnostic message(s) 734 and alarms and displays 738. In a predictive wellness mode, the predictive knowledge base 740 is used in lieu of the diagnostic knowledge base 720, as described with respect to FIG. 8, below.

In an embodiment, a wellness index 732 is a numerical, alphanumeric, color or other scale or combination of scales that embodies the sum total of a diagnostic output 712. For example, a wellness index of 10 indicates no significant problems or issues reported by any system block; a wellness index of 8 indicates a minor problem reported by at least one system block; a wellness index of 6 indicates a significant problem reported by at least one system block or minor problems reported by multiple system blocks; a wellness index of 4 indicates significant problems reported by multiple system blocks; and a wellness index of 2 indicates a major problem reported by at least one system block.

In an embodiment, a diagnostic message 734 is natural language text indicating a clinical decision in response to system status codes 701. For instance, a diagnostic message might state a potential cause for specific symptoms such as “patient displaying symptoms of apnea.” In an embodiment, the diagnostic message 734 might also suggest a remedy for the symptoms or a possible course of treatment. indicators that alone or combined with other wellness state outputs 732, 734 function to communicate specifics regarding patient health or illness to a caregiver. Alarms include single frequency, mixed frequency and varying frequency sounds. Displays include text; bar, Cartesian, polar or 3-D coordinate graphs; and icons to name a few.

FIG. 8 illustrates a predictive wellness analyzer 800 having a monitor 810, one or more adjunct layers 830, 850 and a simulator 870. The monitor 810 has parameter logic blocks 804, system logic blocks 806, one or more diagnostic logic blocks 808, a controller 807 and a predictive wellness output 809. In an embodiment, the predictive wellness analyzer 800 utilizes the same hardware/software resources as the wellness analyzer 300 (FIG. 3). That is, in a predictive wellness mode, the controller 807 disables one or more of the sensor inputs 801 and/or parameter logic blocks 804 and enables the simulator 870. The controller 807 also configures the system logic blocks 806 to access stored features 630 (FIG. 6) and configures the diagnostic block 700 (FIG. 7) to utilize the predictive knowledgebase 740 (FIG. 7) in lieu of the diagnostic knowledgebase 720 (FIG. 7). So configured, the predictive wellness monitor 810 advantageously tests a virtual patient constructed from a history of patient monitoring and information provided by adjunct layers 830, 850 to assess patient near-term health risks and, perhaps, longer term susceptibility to disease and other health threats, as described above.

As shown in FIG. 8, the simulator 870 synthesizes one or more sensor inputs 801 and/or one or more parameter 804 outputs. For example, the simulator 870 may generate a first parameter block 812 output according to a first probability distribution 813; disable a second parameter block 814; and generate an nth parameter block 818 output according to an nth probability distribution 819. In an example based upon FIG. 4, oxygen saturation 422 (FIG. 4) is varied, say, between 85-95% and pulse rate 424 (FIG. 4) is varied, say, between 100-150 bpm. Accordingly, respiration rate 432 (FIG. 4), temperature 416 (FIG. 4) and blood pressure 442 (FIG. 4) are allowed to vary as dependent parameters based upon the simulated blood pressure and respiration rate. That is, the non-simulated parameters vary according to the historical (stored) patient responses to like variations in oxygen saturation and pulse rate. In this manner, the likely response of a patient's respiratory system and hemodynamics to normal variations in oxygen delivery are measured.

Further shown in FIG. 8, the simulated parameters 813, 819 feed the system logic blocks 806. In the predictive mode, the controller 807 alters the system block 806 pathways so that the system status outputs 805 are responsive only to the simulated parameters 813, 819 and the stored features 632 (FIG. 6) recorded by the feature extractor 620 (FIG. 6) in the wellness mode. Hence, the extracted features of simulated (independent) parameters trigger the recall of dependent parameter features based upon monitored history. Accordingly, the system blocks 806 generate a system status 805 that reflects both the simulated parameter inputs 813, 819 and the historical patient response to those parameters.

Continuing the example based upon FIG. 4, as oxygen saturation and pulse rate are generated by the simulator 870, the feature storage of the system blocks 806, in “playback” mode, internally generates the corresponding “predicted” respiration rate, temperature and blood pressure parameters. The corresponding system status 805 is input to the diagnostic block 808, which generates a predictive wellness 809 output, which differs from the wellness output 703 (FIG. 7). In an embodiment, instead of a clinical diagnosis of an existing condition based upon the diagnostic knowledge base 720 (FIG. 7), predictive wellness indicates the likelihood of a near-term deterioration of an existing condition, such as a risk of infection, septic shock or an adverse drug reaction, to name a few, according to the predictive knowledge base 740 (FIG. 7).

A wellness analysis system has been disclosed in detail in connection with various embodiments. These embodiments are disclosed by way of examples only and are not to limit the scope of the claims that follow. One of ordinary skill in art will appreciate many variations and modifications. 

1.-20. (canceled)
 21. A wellness analyzer system comprising: a plurality of sensors configured to generate real-time physiological data from a patient; a plurality of databases configured to provide non-real-time information relevant to a medical-related assessment, the plurality of databases comprising patient-specific databases and non-patient-specific databases; and a wellness monitor including one or more processors, wherein the one or more processors are configured to receive the real-time physiological data and the non-real-time information, process the real-time physiological data to obtain a plurality of physiological parameters, and process the non-real-time information to generate supplemental information, the wellness monitor further configured to: in a diagnostic mode, generate a wellness output based at least in part on one or more features of the plurality of physiological parameters and the supplemental information; and store the one or more features in a memory of the wellness monitor; and in a predictive mode, construct a virtual patient model from at least the non-real-time information and test the virtual patient model to assess a health risk of the patient in response to predetermined physical, medical or environmental conditions, wherein the wellness monitor is configured to test the virtual patient model based on one or more simulated physiological parameters and the one or more features stored in the memory.
 22. The system of claim 21, wherein the virtual patient model is constructed further based on a history of patient monitoring information.
 23. The system of claim 21, wherein the one or more processors comprise a monitor logic layer configured to extract the one or more features of the plurality of physiological parameters.
 24. The system of claim 23, wherein the one or more processors further comprise adjunct logic layers configured to process the non-real-time information to generate the supplemental information.
 25. The system of claim 24, wherein each of the adjunct layers is specialized to process data according to a source of the data.
 26. The system of claim 21, wherein the health risk is a risk of infection, septic shock, embolism, pneumonia, or adverse drug reaction.
 27. The system of claim 21, wherein the health risk is a long-term susceptibility to a disease.
 28. The system of claim 21, wherein the wellness monitor is configured to output an assessment of the health risk as a predictive wellness index.
 29. The system of claim 21, wherein the wellness monitor is configured to output an assessment of the health risk in a listing of specific health risks.
 30. The system of claim 29, wherein the listing of specific health risks is sorted according to priority or urgency for a follow-up examination or treatment.
 31. The system of claim 21, wherein the plurality of sensors are configured to measure at least one of an oxygen saturation, pulse rate, total hemoglobin, temperature, or respiration rate of the patient.
 32. The system of claim 21, wherein the plurality of sensors comprise a plethysmographic sensor.
 33. The system of claim 21, wherein the patient specific databases comprise a medical history of the patient.
 34. The system of claim 21, wherein the patient specific databases comprise a lab report or a test result of the patient.
 35. The system of claim 21, wherein the patient specific databases comprise one or more of prescribed medications or prescribed therapies of the patient.
 36. The system of claim 21, wherein the patient specific databases comprise a family history, genealogy, genetic information, or environmental information of the patient.
 37. The system of claim 21, wherein the non-patient-specific databases comprise scientific research information.
 38. The system of claim 21, wherein the non-real-time information comprises local databases in communication with the wellness monitor via a local area network.
 39. The system of claim 21, wherein the non-real-time information comprises non-local databases in communication with the wellness monitor via a wide area network. 